Such a method is used in the field of automation technology. An automation system is used to solve a control problem or assumes the control of a process. It reads the values of sensors and operating elements and processes these with internal states into output values for actuators. A modern automation system consists to a significant extent of software, in order to allow it to be adapted by users to suit their particular tasks.
The programming of an automation system differs from the programming of other areas. The program which executes month-end processing in a bookkeeping system for example has a clear beginning and a clear end with a short run time. Care must be taken in this case that it can only be activated once a month. If an automation system controls an elevator for example, then the program remains in operation for as long as the elevator is in operation. The length of the two programs may be approximately the same, but the run time and the general conditions differ greatly however. The program is constantly repeated by the firmware of the automation system. In automation systems the programming is referred to as cyclic programming. The run time must be short, since this approximately corresponds to the reaction time of the controller.
The automation system is not normally programmed at the automation system itself, since it has no screen and no keyboard—except where it needs these for handling the control task. Normally a programming device is used, generally consisting of a commercially available PC with a connection facility to the automation system and the necessary software. After the program has been created it is transmitted to the automation system and executed there. The user programs the solution of his control task in programming languages, such as those described in IEC 1131-3.
When an automation system is commissioned situations are encountered in which there is a desire to observe the program. In such cases this observation is to take place during operation with minimal intervention into the running program, i.e. not in the way that such requirements are dealt with on a PC. Tasks are transmitted to the automation system over the connection between programming device and automation system, executed there and the result is transmitted back to the programming device.
A protocol is described in EP 1 119 801 B1 which makes it possible to monitor the execution of the machine commands of the automation system. The software running on the programming device for observation, known as the debugger for short, assigns the observed values at the machine commands back to the language constructs. This requires that the machine commands necessary for the observation of the program are known for the language construct on the programming device.
A method is described in WO 2004/015564 A2 in which debugging can be implemented even if the concrete implementation of the machine commands is not known by a standard controller. The disadvantage of the methods described is the tendency for nothing to be recorded with commands which are only run sporadically. The primary reason for this is that the programming devices use operating systems with windows and multitasking, as will be illustrated using a Windows PC as an example.
The communication facilities of a Windows PC are on one hand very diverse, on the other hand its reaction behavior leaves much to be desired. Windows programs must make do with one event queue per window. All events for this window are arranged in this one queue. The events from this queue are processed on after the other in sequence. Regardless of the communication path used, in the final analysis everything is synchronized via this event queue. The detrimental result of this is that the number of events per second for an additional task such as the debugging may not be greater than the frequency with which keyboard and mouse are polled. If these limits are slightly exceeded, the Windows PC reacts sluggishly; the mouse cursor starts to jump around. If these limits are greatly exceeded, the computer only reacts very sporadically to user entries. This must be avoided. The most important ancillary task of all driver programmers is for the necessary data to be filtered through the system, but for the number of the events to remain low for synchronization with the window system. This problem thus relates to all systems with windows and multitasking and is not just to be encountered in Windows.
For the debugging of automation systems this state of affairs thus presents itself as follows: A program runs on the automation system. A specific sequence of commands is to be monitored. For this sequence of commands a monitoring job is transmitted from the programming device to the automation device. When the commands concerned are run, the requested data is recorded once. The monitoring job is then blocked. The recorded data is transmitted to the programming device. The received data is filtered through the various driver layers. At some time or other they are then processed up to the point at which they can be output. To this end an event must be sent to a window. This in its turn is distributed to a method which in the final analysis edits the data so that the window can be redrawn. The programming device thus displays the data, the user can see it. So that the system remains operable, at least one keyboard request is now awaited before a release is sent by the programming to the automation device for the monitoring task. If the commands concerned are run thereafter, the sequence begins again.
The flow control described here now has the desired result that the programming device remains operable. If a command sequence is executed more often on the automation system than is the reaction time of the flow control, then not every execution can be observed. This does not actually present any problem. The keyboard polling typically occurs 60 times per second. In the ideal case 60—typically a third thereof, i.e. 20—data packets per second are displayed. At this speed a person can read everything.
The problem arises with sporadically executed commands. Example: An IF-THEN-ELSE has been programmed in ST (Structured Text, one of the IEC 1131 languages). The condition will however only be fulfilled on every hundredth execution, i.e. the THEN branch is only performed for every hundredth execution, whereas the condition is executed each time. Let us further assume that the IF-THEN-ELSE is executed 1000 times per second. With 20 recordings per second 980 executions are lost. In this time there were only 10 opportunities to also observe the THEN branch. Thus the THEN has only been recorded 0.2 times on average. Which means in practice that the THEN branch is only seen after several seconds, or not at all.
In practice however it is often the rarely executed branches of a program which present problems, since they deal with any exceptions. But it is precisely these branches that are very hard to observe.